捷運客服拒絕回答「今天天氣如何」，可以是一個合理的產品選擇。前提是服務範圍已經說清楚，而且遇到「颱風會影響營運嗎」時，仍能辨認出應該受理的需求。

這兩句話都沒有辱罵、沒有個資，也沒有要求執行危險動作。差別在於使用者要查天氣預報，還是想確認搭乘是否受到影響。本文沿用捷運客服作為假設場景，從這個差別討論服務邊界。

前一篇談 HAP 時，重點是不要因為顧客帶著情緒，就中斷原本應該提供的服務。今天換一個方向：當請求本身沒有安全問題，企業仍然需要決定這個客服要不要受理。

離題防護（Off-topic Guardrails）處理的就是這個問題。它把客服允許處理的任務，落實成對話中的受理、澄清與拒答條件，讓使用者知道哪些回答屬於這個服務的責任。

先決定客服接什麼工作

筆者原本在自訂驗證器示範裡，以捷運客服比較兩種請求：詢問淡水到台北車站的搭乘方式，以及要求用 Python 寫出楊輝三角形。前者進入客服流程，後者回覆服務範圍，並提示使用者可以問路線、票價或站內設施。

這個例子容易判斷，因為兩個任務相差很遠。放進真正的對話時，第一個需要補清楚的條件，是「捷運相關」到底包含什麼。

假設客服提供搭乘規劃、票價、營運公告與遺失物辦理方式，那麼「怎麼搭車」與「東西掉在車上要找誰」都有對應的服務。餐廳推薦、一般程式教學與天氣預報，則先列為不受理。這是本文的示意範圍，沒有替任何實際捷運客服制定政策。

這些範圍應由負責服務的業務人員確認。若只在提示裡放一句「僅回答捷運相關問題」，工程師與模型都還得自行解釋邊界。同一個問題被不同版本判成不同結果時，也無從知道是分類出了錯，還是服務規則根本沒說清楚。

允許多少聊天，同樣是產品選擇。簡短招呼可以幫助使用者開始查詢；長篇閒聊則會占用服務資源。可以允許「你好」並介紹服務，也可以在使用者持續要求聊天時，引導回查詢。沒有必要為了限制領域，連開始對話的入口都一起拒絕。

都提到天氣，要求完成的任務可能不同

沿用這個捷運客服，看看兩句話：

今天天氣如何？

今天颱風會影響捷運營運嗎？

第一句要的是天氣預報，第二句要的是營運資訊。若客服的服務範圍包含營運公告，第二句就有受理的理由。把「天氣、颱風、下雨」列成一律阻擋的字詞，會把本來可以處理的需求一起擋掉。

判斷要看的，是使用者要求完成什麼工作。背景裡提到天氣，可以是查詢營運的原因；在程式題前面加上「捷運」兩字，也不會自動讓它變成搭乘服務。

例如「幫我寫 Python，計算捷運各站之間的路線」，主題確實涉及捷運，但交付物是程式。如果這個客服只提供搭乘查詢，仍然可以拒絕程式教學，改問使用者要從哪一站到哪一站。若產品原本就提供開發者服務，判斷才會不同。

有些請求還需要前後文。使用者先問颱風期間的營運，接著只說「那明天呢？」；單看最後一句，很難知道他要查什麼。這時應沿用已確認的查詢脈絡。若一開始就只問「今天會停嗎？」，則可以先確認是不是在問捷運營運，以及哪條路線。

先確認缺少的資訊，再決定是否受理，能減少因為問題太短而拒絕正常需求的情況。

禁止某些主題，與只受理某些業務，設定方式不同

選工具時，要看它怎麼表達範圍。

Amazon Bedrock 的 Denied topics 文件要求明確描述要禁止的主題，並提醒不要用「某領域以外的全部內容」這種負向定義，也不要把主題過濾當成字詞比對。

因此，列出投資建議、政治討論等禁止主題，還不能完整定義一個捷運客服。程式教學或食譜可能沒有命中這些項目，卻仍然不在客服的業務範圍內。要實現範圍限制（Scope Enforcement），還需要把請求對應到允許提供的任務，並處理找不到對應任務的情況。這是根據介面限制推導出的設計要求。

NVIDIA NeMo Guardrails 的 Topical Rails 教學則列出從輸入、輸出與對話流程控制主題的方式。這也提醒我們，使用者問得合理，模型回覆仍然可能延伸到服務範圍之外。

例如詢問搭乘方式，回覆卻順便推薦餐廳。如果本例政策只允許交通服務，輸出就需要在交付前回到原本的查詢任務。只檢查使用者輸入，無法處理回覆自己離題的情況。

在本例中，還需要用台灣客服的省略句與多輪對話確認判斷是否合適。官方教學提供控制方式，沒有替這個服務決定業務邊界。

願意受理，也要有資料能回答

回到「今天颱風會影響捷運營運嗎？」。把它判為業務範圍內，只表示客服願意處理這個任務；接下來仍要取得適用的營運資訊。

若沒有最新公告，客服可以說明目前無法確認，提供官方查詢入口。不能因為主題相關，就讓模型依一般常識猜今天是否停駛；也不宜回「這與捷運無關」，把缺少資料誤說成使用者問錯地方。

這兩種情況對使用者的影響不同，也需要不同修正。離題是服務不受理；缺少資訊是任務可以受理，但目前無法提供可靠答案。把它們都壓成同一句拒答，會讓業務人員看不出應該調整範圍，還是補上資料來源。

不當使用（Improper Usage）也不能直接等同於所有離題請求。有人可能只是把客服當成通用助理，或不知道這個服務能做什麼。單憑一句天氣問題，沒有理由推定他在攻擊系統。先說明服務範圍，就能處理許多這類誤會。

拒答之後，讓使用者找得到可用的服務

對第一句天氣問題，本例可以回：

我提供捷運路線、票價與營運資訊，無法查詢天氣預報。如果你想確認天候是否影響搭乘，可以告訴我路線或車站。

這段回覆交代了限制，也保留和客服任務相接的下一步。它沒有宣稱今天正常營運，更沒有責備使用者問了不當問題。

若使用者同時問「幫我查搭乘路線，順便寫一段 Python」，而政策允許分開處理，就可以受理搭乘查詢，同時說明不提供程式教學。整段是否要拒絕，應依任務與政策決定；不能只是找到一個離題部分，就默默丟掉其他需求。

對這個捷運客服而言，拒絕提供天氣預報有清楚的理由：它沒有承諾這項服務。至於天候影響營運的問題，仍然應該有機會被受理。Off-topic Guardrails 要落實的，正是這種能向使用者解釋、也能讓業務人員確認的服務範圍。

參考資料

• 深入 Guardrail 的世界！使用 LiteLLM 和 Guardrails.ai：本文沿用其中捷運客服的意圖辨識與拒答引導，延伸討論業務範圍。
• Amazon Bedrock：Denied topics 與定義限制
• NVIDIA NeMo Guardrails：Topical Rails（Colang 1.0 教學）